😡 How to: не писать `__init__`

До Python 3.7, если вы хотели создать объект Coordinate(x=1, y=2), приходилось писать:

class Coordinate:
    def __init__(self, x: int, y: int):
        self.x = x
        self.y = y

Это выглядело нормально. Но:
📍 если убрать класс из API — теряется типизация;
📍 если разрешить создавать объект без данных — получаем некорректные объекты;
📍 если задать поля по умолчанию — объект становится мутируемым;
📍 для валидации нужно усложнять структуру.

✅ Главная проблема

__init__ запускает код при каждом создании объекта, что усложняет работу, особенно если нужны побочные действия (например, открытие файла).

Пример проблемного кода:

class FileReader:
    def __init__(self, path: str):
        self._fd = fileio.open(path)

Вроде удобно. Но:
📍 Вы не можете передать fd напрямую — нужно городить object.__new__.
📍 Тестировать сложно — надо мокать fileio.open.
📍 Если open становится async, вам уже не обойтись __init__.

Ключевая ошибка: связывать создание объекта с побочными эффектами (например, I/O) — это антипаттерн.

✅ Современное решение

1⃣ Используйте @dataclass для объявления:

@dataclass
class FileReader:
    _fd: int  # или лучше: FileDescriptor

2⃣ Вынесите создание объекта в @classmethod:

from typing import Self

@dataclass
class FileReader:
    _fd: int

    @classmethod
    def open(cls, path: str) -> Self:
        return cls(fileio.open(path))

Теперь создавайте объект так: FileReader.open("file.txt"), а не через __init__.

Это решение поддерживает:
📍 чистую типизацию
📍 возможность перехода на async
📍 множественные фабрики (from_fd, from_buffer, from_resource, ...)

3⃣ Типизируйте примитивы через NewType:

from typing import NewType
FileDescriptor = NewType("FileDescriptor", int)

Используйте в классе:

@dataclass
class FileReader:
    _fd: FileDescriptor

    @classmethod
    def open(cls, path: str) -> Self:
        return cls(fileio.open(path))  # пусть возвращает FileDescriptor

✅ Новая практика для классов в Python:
1. Используйте @dataclass.
2. Не пишите __init__ вручную.
3. Добавляйте @classmethod-фабрики (.open(), .from_config(), .from_env()).
4. Используйте NewType.

✅ Это даёт чистый, тестируемый, удобный и расширяемый код.

Библиотека питониста #буст

💭 Холивар: f-строки vs .format() vs %

Python предлагает сразу три способа форматирования строк — и у каждого есть свои фанаты.

Разбираемся по фактам:

🔎 f-строки (Python 3.6+):

name = "Alice"
age = 30
print(f"{name} is {age} years old.")

✅ читаемо, лаконично
✅ быстрее при выполнении
🙅‍♂️ не работает в Python < 3.6
🙅‍♂️ неудобно при кавычках внутри строк

🔎 .format():

name = "Alice"
age = 30
print("{} is {} years old.".format(name, age))

✅ кросс-версионно (Python 2.7+ и 3.x)
✅ хорош для шаблонов и повторов
🙅‍♂️ длиннее, особенно с ключами
🙅‍♂️ легко запутаться с порядком аргументов

🔎 Cтарый стиль %:

name = "Alice"
age = 30
print("%s is %d years old." % (name, age))

✅ кратко для простых случаев
✅ работает даже в старом Python
🙅‍♂️ типобезопасность на минималках
🙅‍♂️ легко сломать, особенно при refactoring’е

Выбор зависит от контекста:
🔘 f-строки — выбор для современного Python-кода
🔘 .format() — для совместимости и шаблонов
🔘 % — для ностальгирующих и логов

А вы что используете чаще всего?

❤️ f-строки — будущее уже здесь
👍 .format() / % — стабильность и привычка

P.S. Инструкция, как оставить коммент

Библиотека питониста #междусобойчик

♻️ Garbage Collector в Python — как он реально работает

Python сам управляет памятью, но делает это не одним, а двумя способами одновременно:

1⃣ Подсчёт ссылок (Reference Counting)

Каждый объект в Python хранит число ссылок на себя:

import sys

a = []
print(sys.getrefcount(a))  # покажет количество ссылок на объект

📝 Когда ссылок становится 0 — объект немедленно удаляется, и память освобождается.
✅ Быстро и просто.

❗️ Проблема: не справляется с циклическими ссылками:

a = []
a.append(a)  # теперь объект содержит ссылку на себя

2⃣ Поколенческий сборщик мусора (Generational GC)

Чтобы находить такие циклы, Python использует модуль gc. Все объекты отслеживаются по «возрасту»:
📝 Поколение 0 — новые объекты
📝 Поколение 1 — выжили после первой сборки
📝 Поколение 2 — считаются «старожилами»

Чем старше объект, тем реже его проверяют, чтобы не тратить ресурсы:

import gc

gc.collect()            # вручную запустить сборку мусора
gc.get_count()          # сколько объектов в каждом поколении
gc.get_threshold()      # когда запускать сборку

✅ Почему это важно:
📝 GC работает фоном и почти незаметно, но может вызвать лаги, если не оптимизировать.
📝 Вы можете влиять на GC: отключать, настраивать пороги, анализировать поведение.
📝 В больших проектах с долгоживущими объектами важно знать, в каком поколении что живёт.

Библиотека питониста #буст

🖥 Бэкенд для ML-проектов: от архитектуры до подводных камней

Если вы работаете с машинным обучением в реальных продуктах, то знаете:
🔹 обучить модель — это только начало
🔹 внедрить её в стабильный продакшен — совсем другая задача

В статье разбираем:
➡️ как обрабатывать фичи в реальном времени
➡️ как версионировать данные и модели
➡️ как избежать рассинхрона между тренировкой и inference
➡️ что тормозит ML-системы в бою — и как это предсказуемо

📖 Читайте статью:
«Бэкенд под ML-проекты: особенности архитектуры и типичные узкие места»
→ https://proglib.io/sh/xCfXt2pH4j

Библиотека питониста #буст